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APPLICATIONS AND SERVICES SUPPORTED BY A CLIENT-SERVER 
INDEPENDENT INTERMEDIARY MECHANISM 
FIELD OF THE INVENTION 

The present invention relates to client-server communication, and more 
5 specifically, to using an independent intermediary mechanism between a client 
and a server. 

BACKGROUND 

The World-Wide Web (WWW, W3, the Web) is an Internet client-server 
hypertext distributed information retrieval system. An extensive user 
10 community has developed on the Web since its introduction. 

Figure 1 is a block diagram of a prior art client-server system. The client A 
110 can access destination servers DS1-DS3 150-170. Similarly, other clients B 
and C, 120 130, can access the destination servers DS1-3 150-170. Each 
destination server may provide different services, information, or other data to 
15 the user. 

On the Web everything (documents, menus, indices) is represented to the 
user as hypertext objects in hypertext markup language (HTML) format, or as 
Java, or JavaScript objects, or other data types. Hypertext links refer to other 
documents by their uniform resource identifiers (URIs). The client program, 
20 known as a browser, e.g. NCSA Mosaic, Netscape Navigator, runs on the user's 
computer and provides two basic navigation operations: to follow a link or to 
send a query to a server. Users access the web through these browsers. 

Users often access the web from multiple locations. Users may access the 
web from their office, at different locations at work, at home, or on the road. 
25 Libraries and Internet cafes make web access available on a walk-in basis as well. 

A user accesses a server by typing the URI of the server into the browser's 
address window. The browser then connects to the server corresponding to this 
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URL Another method of accessing a web site is by selecting the web site from 
the list of bookmarks. The list of bookmarks is resident in the browser in the 
user's computer. Thus, if a user wishes to have similar bookmarks on multiple 
computers, he or she must manually copy the bookmarks and transfer them 

5 between the computers. This process is inconvenient. 

Furthermore, many servers use cookies to store information about the 
user. This information may include the user name, password, previous interests, 
etc. These cookies are also stored in the user's browser. Again, this means that if 
the user is accessing the Internet from multiple computers, the user's cookies 

10 have to be duplicated into multiple computers. This process is inconvenient. 

Many users have multiple accounts on different computer systems. For 
example, a user may have an account with a bank, an e-mail account, a 
personalized portal site account, and an account on an e-commerce server. 
Currently, the users must log into each of these accounts by remembering and 

15 providing his or her user name and password. For security, each of these user 
names and passwords should be different. Remembering different names and 
passwords is inconvenient to the user. Thus, a method for a simple log-in into 
various accounts from any computer would be advantageous. 

Most clients and servers support "forms" which allow the user to enter 

20 arbitrary text as well as selecting options from customizable menus and on/off 
switches. As more business is transacted on the Web, forms are proliferating. 
The forms may include forms for requesting further information, for ordering 
items from the Web, for registering for a Web site, etc. However, the user 
generally can not get a copy of the information filled into the form. The user can 

25 either print the page when the form is filled in, generating a paper copy, or rely 
on the server to respond in a manner that permits the user to make a record of 
the information entered in to the form. A method of tracking information filled 
into forms would be advantageous. Furthermore, vendors may respond with an 
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order number or other useful information. The user can keep a copy of this page, 
which is generally only temporarily available, by printing it, or copying down 
the information provided. A method of attaching this vendor response to the 
original order information and making both available to the user would be 

5 advantageous. 

Furthermore, currently, the user has to fill out each of these forms 
separately. Generally, the forms request the same types of information, i.e. name, 
address, telephone number, e-mail address, etc. The user has to enter all of this 
information for each form. This is repetitious and takes time. Additionally, if 

10 such information as credit card number or social security number is requested, 
the user has to pull out the credit card and copy a long string of numbers. This 
makes errors likely. Furthermore, the user has to verify that a Web site that 
requests a credit card number or similar confidential information is of the 
appropriate level of security for the user to feel comfortable sending the 

15 information over the Web. An improved method of filling out forms would be 
advantageous. 
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SUMMARY OF THE INVENTION 

A method and apparatus of accessing data through an independent 
intermediary mechanism (IIM) is described. The method includes displaying a 
frame including a user interface of the IIM, the frame framing a destination 
5 server display area (DSD A). The method further includes having one or more of 
the following functions provided by the IIM: a home page, a history list, 
bookmarks, a one-click account log-in function, a transaction record accessible to 
the user, a forms database permitting new forms to be added to the forms 
database, a user profile, and automatic form-fill function based on the forms 
10 database and the user profile. 



003982.P002 



-4- 



BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention is illustrated by way of example, and not by way of 
limitation, in the figures of the accompanying drawings and in which like 
reference numerals refer to similar elements and in which: 
5 Figure 1 is a block diagram of a prior art client-server system. 

Figure 2 is a block diagram of one embodiment of the client-server system 
including the independent intermediary mechanism. 

Figure 3A is a block diagram of one embodiment of the client-server 
system including multiple independent intermediary mechanisms. 
10 Figure 3B is a block diagram of another embodiment of the client-server 

system including multiple independent intermediary mechanisms. 

Figure 4 is a block diagram of one embodiment of the independent 
intermediary mechanism. 

Figure 5 is a block diagram of one embodiment of the layout of the user 
15 interface of the independent intermediary mechanism. 

Figure 6 is a flowchart of an overview of using the independent 
intermediary mechanism. 

Figure 7 is a flowchart of one embodiment of the process of displaying 
information from a destination server through the independent intermediary 
20 mechanism. 

Figure 8 illustrates one embodiment of the user interface of the 
independent intermediary mechanism. 

Figure 9 illustrates another embodiment of the user interface of the 
independent intermediary mechanism. 
25 Figure 10 is a flowchart of one embodiment of the form fill functionality. 

Figure 11 is a flowchart of one embodiment of the learning process in the 
database. 

Figure 12A is a flowchart of one embodiment of adding accounts. 
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Figure 12B is a flowchart of one embodiment of accessing an account 
through an auto-log-in feature. 

Figure 13 is a flowchart of one embodiment of the transaction 
management functionality. 
5 Figure 14 illustrates one embodiment of the listing of transactions. 

Figure 15A is a flowchart of one embodiment of selection of a home page 
or a bookmark. 

Figure 15B is a flowchart of one embodiment of using the bookmark 
functionality. 

10 Figure 15C is a flowchart of one embodiment of using the history 

functionality. 

Figure 16A-C are tables illustrating examples of redirecting references to 
DS through EM. 

Figure 17 is a table illustrating examples of making the EM user interface 
15 frame persistent. 

Figure 18 is a table illustrating examples of accessing cookies from the 

IIM. 

Figure 19 is a table illustrating examples of preserving top frame or IIM 
frame integrity for DS. 
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DETAILED DESCRIPTION 

A client-server independent intermediary mechanism is described. The 
independent intermediary mechanism (IIM) mediates information exchanged 
between a client and servers by having the client-server communication pass 
through the IIM. This allows the EM to offer various services. For one 
embodiment, the EM may be used to have a central web-accessible set of 
bookmarks. The IIM may further provide tracking of transactions on the web, 
providing a user-accessible transaction record. The IIM may further be used to 
fill in various forms automatically. The IIM may further be used to access 
multiple accounts, such as e-mail accounts, bank accounts, etc. with a single 
button. The IIM may further be used to store the user's profile, including 
passwords to various pages, etc. These and other uses of the IIM are described 
below. 

Figure 2 is a block diagram of one embodiment of the client-server system 
including the independent intermediary mechanism. Multiple clients A-C 210, 
215, 220 access multiple destination servers (DSs) 280, 285, 290, through the 
independent intermediary mechanism (IIM) 250. Client A 210 is described as an 
example. It is to be understood that multiple clients are implemented in similar 
ways. 

Client A 210 accesses the IIM 250. For one embodiment, this occurs when 
the user of the client A 210 accesses the web site hosting the EM 250. When the 
EM 250 is accessed, a new client component (CC) 230 is established. The client 
component(s) 230, 235, 240 and the server component 260 together form the EM 
250. For one embodiment, the IIM 250 is located on a server accessed by the 
client A 210 through an Internet connection. For another embodiment, the IIM 
250 is located within the local Intranet of client A 210. For yet another 
embodiment, the EM 250 is located on the client's own computer. 
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For one embodiment, the client component 230 is established on the local 
computer of the client 210. For another embodiment, the client component 230 is 
on a server, or on a third computer system. The client component 230 is created 
in response to the client 210 connecting to the IIM 250. 
5 The client A 210 has a connection to the server component 260 through the 

client component 230. For one embodiment, the client A 210 also establishes a 
direct connection with the server component 260. This direct connection may be 
used to communicate certain information directly between the server component 
260 and the client A 210. The client 210 accesses the destination servers DS1-3 

10 280, 285, 290 through the IIM 250. For one embodiment, all of the 

communication between the destination server DS1 280 and the client A 210 is 
routed through the IIM 250. For another embodiment, certain communications 
are routed directly between the client A 210 and the destination server 280. For 
example, certain large images that do not invoke other images or other data may 

15 be routed directly in order to speed up processing. 

The number of client components 230, 235, 240 depends on the number of 
clients 210, 215, 220 coupled to the server component 260 at any one time. For 
one embodiment, the server component 260 consists of multiple components that 
act together. A block diagram of one embodiment of the DM 250 may be found 

20 in Figure 4, below. 

Figure 3A is a block diagram of one embodiment of the client-server 
system including multiple independent intermediary mechanisms 350, 360. Each 
IIM 350, 360 is shown having a corresponding server component, 355, 365. For 
another embodiment, the server components 355, 365 may be located on a single 

25 server, or within a single IIM. Having server components 355, 365 coupled 

together may serve multiple purposes. For example, if a single IIM 350 has too 
many users connected to it, the HM 350 may redirect users to a second IIM 360. 
For another embodiment, a user may log on to a local EM 350, for speed reasons, 
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and the local IIM 350 may connect to the user's "home" IIM 360 to retrieve the 
user's data. For yet another embodiment, the user can connect to their "home" 
IIM 350, which is remote, and the "home" IIM 350 may redirect the user to a local 
IIM 360 and send the user's data to the local IIM 360. In this way, the user's 
5 connection to the IIM 350, 360 may be optimized. 

Figure 3B is a block diagram of another embodiment of the client-server 
system including multiple independent intermediary mechanisms. In this 
example, a client 310 is coupled to two DMs 350, 360. Generally, the client 310 
first connects to the first IIM 350. Then, through the user interface of the first 

10 IIM, the client 310 connects to the second IM 360. This may be advantageous if, 
for example, the first IIM 350 and second IIM 360 provide different services. 
Thus, for example, one IIM 360 may provide additional account management 
features, while the other IIM 350 provides form-fill features. By connecting to 
both IIMs 350, 360, in series, the user has access to the features provided by both 

15 IIMs 350, 360. 

Figure 4 is a block diagram of one embodiment of the independent 
intermediary mechanism. The IIM 400 has three layers. The lowest layer of the 
IIM 400 is the core engine 410. The core engine 410 includes a server component 
SC and a client component CC. The Server Component, for one embodiment, is 

20 resident on the server, and handles all remote actions. The Client Component, 
for one embodiment, is resident on the client's system, while the client is 
connected to the IIM 400. For one embodiment, the client component is 
automatically removed from the client's system when the client disconnects from 
the IIM 400. The lowest layer also includes a Cookie Manager 413, for managing 

25 any cookies received from and being sent to the destination server. The use of 
such cookies is discussed in more detail below. Furthermore, the lowest layer 
may include a Activation Manager 416. The Activation Manager 416 determines 
if information is being transmitted by the destination server. For one 
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embodiment, the Activation Manager 416 further determines if information is 
being initiated by a user's action. Information transmitted between the DS and 
the client is instrumented by the IIM 400, as will be described below. The 
Activation Manager 416 detects when the IIM 400 should review communication 
5 between the client and the DS. 

The second layer is the application /UI framework layer 420. The 
application/UI framework layer 420 establishes the basic user interface and IIM 
engine. The application/UI framework layer 420 creates a persistent frame for 
the IIM 400. For one embodiment, the application/UI framework layer 420 

10 further includes an instrumenting manager 425, for instrumenting data flowing 
from the destination server to the client, through the IIM 400. This process of 
instrumenting is described in more detail below. 

The third layer is the applications layer. The applications layer includes 
multiple applications. The applications listed here are listed as an example, and 

15 are not a complete list. The applications layer, for example, may include a 
Navigation Manager 430. The Navigation Manager 430 permits a user to 
navigate from destination server to destination server using the IIM 400. The 
applications layer may further include a Transaction Manager 440. 

The Transaction Manager 440 tracks the user's transactions, stores them, 

20 and makes them available for the user's review. Transactions are interactions in 
which a user submits information to a destination server, for example to order an 
item, ask a question, or otherwise interact with the destination server. The 
Transaction Manager 440 tracks the data submitted by the user, and any 
response from the destination server, and permits the user to access this 

25 information. 

The Account Manager 450 permits the user to log into a variety of 
accounts, from e-mail to stock trading accounts, using a single click. The 
Account Manager 450 further permits the user to add accounts to this list. The 
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Form Manager 460 permits the user to fill out forms encountered on destination 
servers via a single click. This is extremely useful for users that transact business 
on the web, and often fill out identical forms many times. The Profile Manager 
470 is the database of the user's personal information. This information may be 
5 edited by the user, and is used to fill in forms via the form manager 460. The 
Database Manager 480 manages the various databases of the IIM 400. 

The Bookmark Manager 490 permits the user to manage bookmarks 
maintained within the HM 400. Having bookmarks, URIs of pages the user 
wishes to save, available in the IIM 400 permits the user to access his or her 

10 bookmark list from any computer. 

The History Manager 495 permits the user to manipulate the history list of 
sites the user has previously visited. For one embodiment, the user can change 
the permanence of the history lists, for another embodiment, the user can delete 
certain sites from the history list. 

15 The Homepage Manager 497 permits the user to set a homepage that is 

displayed when the user initially connects to the server providing the IIM 400. 

As can be seen, the IIM provides multiple functionalities. A single IIM 400 
may include all of the functionalities described above, additional functionalities, 
or some subset of these functionalities. The IIM's functionality may be extended 

20 with additional features. 

Figure 5 is a block diagram of one embodiment of the layout of the user 
interface of the independent intermediary mechanism. The client browser 
application window 510 is displayed by a browser, such as Netscape Navigator 
or Microsoft Internet Explorer. The client side display area (CSDA) 520 is the 

25 display area available in the browser application window 510. Most browsers 
have a toolbar and other displays within the browser application window 510. 
For one embodiment, the IIM is designed to minimize the area of the browser 
application window that is not the CSDA 520. 
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The CSDA 520 includes a toolbar frame 530. Although the tool bar frame 
530 is referred to as a frame, for one embodiment, the tool bar frame 530 may be 
implemented in a non-frame format. For one embodiment, the tool bar may be 
implemented as a separate window. For another embodiment, the tool bar may 
be implemented as part of the display, not as a frame. 

The CSDA 520 further includes a destination server display area (DSDA) 
540. The DSDA 540 is the area in which all information from destination servers 
is presented. 

The CSDA 520 further includes a communications frame 550. The 
communications frame 550 is for communication between the client side and 
server side of the IIM. Generally, the communications frame 550 is hidden from 
the user's view. Thus, the user would not see the communication between the 
client component and the server component. 

Figure 6 is a flowchart of an overview of using the independent 
intermediary mechanism. At block 610, the user connects to the IIM through the 
client browser. For one embodiment, this is done by typing the address of the 
IIM into the address window of the browser. For one embodiment, the IIM may 
be the preset homepage of the user, or a bookmark in the client browser. 

At block 615, the user connects to a destination server (DS) through the 
IIM. For one embodiment, this is done by typing the address of the destination 
server into the address window of the IIM. For another embodiment, the user 
may select an address from a history list of previously visited sites, from a 
bookmark list in the IIM, or the destination server may be a preset homepage in 
the IIM. The IIM records the DS in the history database. The history database 
tracks the web sites that the user has visited in the past. Such a history database 
may be useful to permit backtracking, or to visit previously visited sites. For one 
embodiment, this history database is maintained for a fixed duration of time, or a 
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user preset period of time. For another embodiment, the history database is 
maintained indefinitely. 

At block 620, the process changes the reference to DS to go through the 
IIM and load the information from the DS in the DSD A, maintaining the IDvl 
5 frame. This is described in more detail below. 

At block 625, the IIM determines whether the user submitted information 
to the destination server. For one embodiment, the actual test is whether 
information that is "sensitive" or "of interest" is submitted to the DS. For 
example, if a user selected a radio button for the next display, the response 

10 would be "no" even though some information was submitted. For one 

embodiment, the answer to this query is yes only if information that is in the 
user's profile is submitted. For one embodiment, the answer to this query is 
provided by the user through the user interface. If the answer is yes, the process 
continues to block 630. 

15 At block 630, the user's communication with the DS is recorded in the 

user's transaction database. For example, if the user ordered an item from a 
destination server site, the form that was filled in by the user, including all of the 
information filled in, would be recorded in the transaction database. This 
transaction database is available to the user. The process then continues to block 

20 635. If, at block 625, the answer was no, the process continues directly to block 
635. 

At block 635, the IIM forwards the communication, i.e. the information 
submitted by the user, to the DS. This communication includes relevant cookies. 
A cookie is a packet of information sent by a destination server to a browser and 
25 then sent back by the browser each time it accesses that server. Cookies can 
contain any arbitrary information the server chooses and they are used to 
maintain state between otherwise stateless transactions. Generally, cookies are 
maintained in a user's browser. However, for one embodiment, the IIM 
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maintains the user's cookies. This permits a user to log into a site, and have the 
appropriate cookies available, no matter from what web client device or client 
browser the user accesses the site. 

At block 640, the process determines whether the destination server 
5 responded to the user's submission of information. For one embodiment, some 
destination servers respond, with a thank you page, other data pertaining to 
order number, shipping code, delivery date, etc., when information is submitted 
to them. If the destination server responds at block 640, the process continues to 
block 645. 

10 At block 645, the DS's response is recorded in the user's transaction 

database, and associated with the user's submitted information. Thus, when the 

user reviews the transaction, he or she can review the entire transaction, 

including the DS's response. 

At block 650, the IIM instruments the DS's response, stores any cookies 
15 returned by the DS, and forwards the response to the client browser. One 

embodiment of this process is illustrated in more detail in Figure 7, below. 

Tables of some results of the process of instrumenting are illustrated in Figures 

16A-C, and Figures 17-19. 

At block 655, the process tests whether the user continues to browse 
20 through the IIM. The user continues to browse, the process returns to block 615. 

Otherwise, the process ends at block 660. 

Figure 7 is a flowchart of one embodiment of the process of instrumenting 

data displayed from a destination server through the independent intermediary 

mechanism. For one embodiment, Figure 7 is a more detailed flowchart of block 
25 650, in Figure 6. At block 705, the IIM receives a communication from the DS. 

For one embodiment, this occurs in response to a user contacting a DS through 

the IIM. 
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At block 710, the process tests whether there is a cookie or multiple 
cookies associated with the communication. Cookies may be sent by the DS to 
the client, to be stored on the client browser. If a cookie is associated with the 
communication, the process continues to block 715. At block 715, the IIM cookie 
5 database is updated with the new cookie. For one embodiment, cookies sent by 
the DS to the client browser are handled through the EM. Thus, the IIM would 
store all of the cookies for a DS, and give the DS its cookies. This is 
advantageous because it permits a user to access a DS from any computer, and 
all of the user's cookies are immediately available through the IIM. The process 

10 then continues to block 725. If no cookies were associated with the 
communication, the process continues directly to block 725. 

At block 725, the process parses the code to find the next keyword. For 
one embodiment, keywords are tags in HTML, or known keywords in Java or 
JavaScript. Figures 16-19 illustrate some examples of keywords that may trigger 

15 this process. For another embodiment, keywords may be any triggering signal 
that indicates that an action may be performed. 

At block 730, the process tests whether a keyword was found. If no 
keyword was found, the process continues to block 735, and ends. If the 
communication has no remaining keywords, the document has been fully 

20 instrumented, and is ready for display to the user. For one embodiment, certain 
communications may have no keywords at all. In that case, this process would 
end after a single pass. For yet another embodiment, under some circumstances, 
the process may ignore certain keywords. Certain references are not altered in 
the communication. For example, references that call static images, images that 

25 do not communicate information to the user and do not have embedded 
references, may be of no interest. For example, if the keyword calls a large 
passive figure with multiple components, the process may ignore the entire 
figure, by tagging figure related communications, and exit out of this process 
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even if keywords remain. By altering only those references that are of interest, 
the process may be sped up. If a keyword was found, the process continues to 
block 740. 

At block 740, the process tests whether the keyword is an attempt to 
5 access a cookie from the cookie database. If the keyword is an attempt to access a 
cookie, the process continues to block 745. At block 745, the access attempt is 
changed to fetch the cookie from the IIM's cookie database. Some examples of 
this process are provided in Figure 18. For one embodiment, the IIM's cookie 
database may access the client browser's cookie database in order to determine 
10 whether there are additional cookies on the client browser. For one embodiment, 
the EM can, with the user's permission, copy cookies from the browser cookie 
database to the IIM. This simplifies moving from direct access of a DS to 
accessing a DS through the IIM. The process then continues to block 750. 

If the keyword is not an attempt to access a cookie, the process continues 
15 directly to block 750. 

At block 750, the process tests whether the keyword is an attempt to 
access the top frame or IIM frame. If the keyword is an attempt to access the top 
frame or EM frame, the process continues to block 755. At block 755, the access 
attempt is changed to access the top area of the destination server display area 
20 (DSDA). Some examples of this process are provided in Figure 17. The process 
then continues to block 760. 

If the keyword is not an attempt to access the top of IIM frame, the process 
continues directly to block 760. 

At block 760, the process tests whether the keyword is a reference to the 
25 destination server. If the keyword is a reference to the destination server, the 
process continues to block 765. At block 765, the reference is changed to be 
fetched through the IIM. Some examples of this process are provided in Figure 
16A-C. The process then continues to block 770. 
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If the keyword is not a reference to the destination server, the process 
continues directly to block 770. 

At block 770, the process tests whether the keyword is an attempt to 
access data from the top frame or IIM frame. If the keyword is an attempt to 
5 access data from the top frame or IIM frame, the process continues to block 775. 
At block 775, the access attempt is changed to fetch data from the topmost frame 
of the DSDA. Some examples of this process are provided in Figure 19. The 
process then returns to block 725, and parses to find the next keyword. 

For one embodiment, the above process may be triggered by a user. For 
10 example, a user may select a link, activate a JavaScript function, or otherwise 
initiate communication between the destination server and the client. The same 
process may occur in response to a cookie being sent or received, or a keyword 
being found as described above with respect to Figure 7. 

Figure 8 illustrates one embodiment of the user interface of the 
15 independent intermediary mechanism. The user interface includes a browser 
toolbar 805. For one embodiment, the IIM may configure the browser such that 
the browser toolbar area 805 is not displayed when the IIM is active. The display 
area 810 of the browser includes the IEVI toolbar 820, a hidden communications 
frame 815, and the destination server display area 845. 
20 The IIM toolbar 820 includes the known browser controls 825, such as 

back, forward, refresh, stop, etc. Additional browser controls 825 may be added. 
The toolbar 820 further includes an address entry control 830, where a user can 
type a destination server address in order to access the DS. 

The IIM toolbar 820 may further include buttons, or other selection 
25 mechanisms that permit a user to configure and use the IIM. The buttons may 
include Home, selecting a user's preset homepage, etc. The homepage is preset 
using the Set Home button 852. The buttons may further include the Mall 
button, giving one-button access to shopping. The buttons may further include 
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Tags 860, displaying a list of a user's bookmarks. Bookmarks are added by 
selecting the Tag Address while visiting a web site, or by selecting the Tag 
Address button 862, and typing the address of a location to be bookmarked. 

The buttons may further include Accounts 865, permitting single-button 
5 log-on to a variety of accounts. These accounts are added with the Add Account 
button 867, as will be described below. 

The buttons may also include a Transactions button 870, that permits a 
user to review his or her transactions. This is illustrated in the destination server 
display area 845 of Figure 8. The Profile button 875 permits the user to enter his 
10 or her personal data. The Fill-Form button 880 permits the user to fill in a form 
using the personal data from the user's profile or by using information submitted 
previously using the same form. If a form is displayed on the destination server 
display area 845, and the user selects the fill-form button 880, the form is 
automatically filled in with the user's information. The Clear Form button 882 
15 permits a user to remove the information filled into a form. This provides an 
additional level of security to the user. 

The Admin button 885 provides access to account administration services. 
For one embodiment, the Admin button 885 is only available to those users who 
are authorized administrators. For one embodiment, the Admin button 885 is 
20 only displayed if the user is authorized to access account administration services. 

The toolbar 820 further includes a Bye button 890, which logs off the user 
from the IIM. The toolbar 820 illustrated is exemplary. The content and 
organization of the buttons on the toolbar 820 may be changed without changing 
the invention. 

25 Figure 9 illustrates another embodiment of the user interface of the 

independent intermediary mechanism. As can be seen, the user interface may be 
flexibly implemented. Certain features may be provided by one interface and 
not provided by another. Furthermore, the look and feel of the user interface 
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may be altered. The user may, for example, access all of the IIM features through 
pull-down menus, such as the pull-down menu 935, or radio buttons instead of 
buttons. One skilled in the art understands other types of user interface changes 
that may be made without departing from the broader spirit and scope of the 
5 invention as set forth in the appended claims. 

Figure 10 is a flowchart of one embodiment of the form fill functionality. 
At block 1010, a document with a form is displayed. For one embodiment, this is 
a result of a user accessing a destination server location that includes a form. 
This form may be an order form, an information request form, or any other form 

10 that may be encountered on the Web. 

At block 1015, the user requests the form-fill function through the IIM 
user interface. For one embodiment, the user presses the form-fill button. For 
another embodiment, the form fill may be automated. For yet another 
embodiment, the user can select whether the form fill function is automatically 

15 engaged. 

At block 1020, the process determines whether the form is in the user's 
transaction database. The user's transaction database has records of previously 
accessed and filled-in forms for the particular user. The transaction database 
may maintain such records for a limited time, or the user may delete transaction 

20 records. Thus, merely because a user has been to a particular site previously 

may not mean that the form is in the user's transaction database. If the form is in 
the user's transaction database, the process continues to block 1040, otherwise, 
the process continues to block 1025. 

At block 1025, the process determines whether the form is in the form 

25 database. The form database is maintained by the IIM and includes "known" 
forms. Such known forms have associations between form control identifiers in 
the form and profile items. Thus, for example, a form control identifier that is 
labeled "name" may have a link to the "First Name Last Name" item in the user 
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profile. If the form is known, the process continues to block 1030. At block 1030, 
the form control identifiers in the form are filled in from the user profile. The 
process then returns to block 1055. 

If the form is not known, the process continues to block 1035. At block 
5 1035, the form controls are identified, based on the name of each control Each 
control name is associated with entries in the user profile. The process then 
continues to block 1030, and the data is filled into the form from the user profile. 
For one embodiment, block 1035 is skipped. This type of "guessing" may be user 
enabled, or may be only attempted for forms that are similar to known forms. 

10 At block 1020, if the form was found in the user's transaction database, the 

process continued to block 1040. At block 1040, the process tests whether any 
data in the user profile has been changed since the transaction in the transaction 
database was recorded. Transaction records are dated, as are changes to the user 
profile. A user profile may be changed by the user, for example, to change a 

15 credit card expiration date, number, or home address. If a user profile change of 
a relevant field is dated after the transaction record date, the process continues to 
block 1045, otherwise, the process continues directly to block 1050. 

At block 1045, the changed information is filled in from the user profile. 
In this way, the user only had to update his or her records once, in the profile, 

20 and that change is carried through the IIM. For one embodiment, this step may 
be skipped. For another embodiment, this step may be user enabled. 

At block 1050, the remaining form control identifiers in the form are filled 
with data from the transaction database. The process then continues to block 
1055. 

25 At block 1055, the filled-in form is displayed to the user, and the user is 

permitted to edit the data in the form. The user, for example, may not wish to 
provide certain data to a destination server. The user may chose to erase such 
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data. Alternatively, the form may request data that is not found in the user's 
profile. The user may chose to fill in such data. 

At block 1060, the user submits the form to the destination server. For one 
embodiment, the IIM stores the information submitted to the server in the user's 
5 transaction database. This is illustrated in Figure 13 below. At block 1065, the 
process ends. For one embodiment, the user may optionally select whether to 
use the user profile, transaction database, or both, and in what order, for form fill 
functions. 

Figure 11 is a flowchart of one embodiment of the learning process in the 

10 database. At block 1110, a privileged user connects to the IBM. For one 

embodiment, this privileged user is an employee of the group maintaining the 
IIM. For another embodiment, this "user" is an artificial intelligence unit that is 
used to identify forms, as will be described below. Such intelligent recognition 
programs are known in the art. 

15 At block 1120, the privileged user accesses a destination server page with 

a form through the IIM. At block 1130, the IIM displays a user interface for 
cataloguing the form. 

At block 1140, the user maps each form control to an element in the user 
profile object. The user profile is set up to contain a large number of possible 

20 data elements. Each form control should have a corresponding profile element. 
If no profile element is found for a form control, that form control may be tagged 
as "form specific/' For one embodiment, multiple elements in the user profile 
may be associated with a single form control, or vice versa. 

At block 1150, other information about the form is added. This 

25 information may include such information as the address of the form, whether 
the connection with the destination server that serves the form is a secure 
connection, whether the form is of a particular classification, etc. 
At block 1160, the user submits the information to the IIM. 



003982.P002 



-21- 



At block 1170, the IIM updates the form identification and form 
description in the form database to include the information added by the user. 
For one embodiment, the updating is a periodic batch updating. For one 
embodiment, a single central form database is maintained. In that instance, the 
5 IIM's updating may include sending the new form to other IIMs. Alternatively, 
each IIM may maintain its own separate form database. For yet another 
embodiment, an IIM may have a central form database, and a separate internal 
form database. This may be useful, for example, for an IIM implemented within 
a company which has the general form database for pages accessed outside the 
10 company, and a separate internal database for internal web page forms. 

At block 1180, the process ends. Of course, the privileged user may enter 
multiple entries, and may start the process again at block 1120. 

Figure 12A is a flowchart of one embodiment of adding accounts. At 
block 1210, the user connects to the IIM through a client browser. At block 1220, 
15 the user accesses a destination server through the EM. For one embodiment, the 
user accesses the account log-in page of the DS. This may be, for example, the 
account log-in page of the user's bank, of a portal, or of any other DS. 

At block 1230, the user requests to add the account to the user's account 
database. Each user may have an account database, which includes a list of 
20 accounts the user can access with a single click. 

At block 1235, the process determines whether the user has submitted log- 
in information to the account log-in page. If the user has not submitted the 
information, the process continues to block 1240, and the user is prompted to 
complete the log-in process. For one embodiment, if the account log-in process 
25 includes multiple pages, the user may indicate the end of the log-in process by 
pressing a certain key, or through other means. The process then continues to 
block 1245. If the user has submitted all of the log-in information, the process 
continues to block 1245 directly. 
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At block 1245, the account entry is added to the user's account database. 
The account log-in information and data of account entry creation are recorded. 
For one embodiment, further information may be recorded. For yet another 
embodiment, only the user's log-in procedure is recorded. 
5 At block 1250, the account information is submitted to the DS for login. 

At block 1255, the process ends. 

Figure 12B is a flowchart of one embodiment of accessing an account 
through an auto-log-in feature. At block 1260, the user connects to the IIM. At 
block 1265, the user accesses the account auto-log-in feature using the IIM user 
10 interface. For one embodiment, this is done by the user pushing the account 
button. 

At block 1270, the user selects an account to log into. For one 
embodiment, the user may have multiple accounts. In that instance, the IIM 
displays the accounts that the user has. For another embodiment, if the user only 

15 has a single account, that account is automatically selected when the user 
accesses the auto-log-in feature. 

At block 1275, the IIM retrieves login information from the user's account 
database. As discussed above, the user's previous account log-in is monitored 
and recorded. This information is retrieved at block 1275. 

20 At block 1280, the IIM sends the log-in information to the appropriate 

destination server to log-in the user. The account information includes the 
address of the DS. The IIM accesses the DS as a client, and sends the user's 
information. 

At block 1285, the IIM instruments the DS's response and sends it to the 
25 user's browser for display. As discussed above, the response is instrumented 

such that references of interest are routed through the EM. The user can now use 
the account, as usual. At block 1290, the process ends. 
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Figure 13 is a flowchart of one embodiment of the transaction 
management functionality. At block 1310, the user connects to the EM. 

At block 1320, the user transmits information in a form to the destination 
server. For one embodiment, the user first accesses a destination server page 
5 including a form through the IIM. This form may be an order form, an e-mail 
form, or any other type of form. The user then fills in the form and submits it to 
the DS. For one embodiment, the user may use the form-fill method described 
above to fill-in the form. 

At block 1330, the process determines whether the user sent the user's e- 
10 mail address to the DS. The user may submit his or her e-mail address so the DS 
can send responses directly to the user's e-mail. For example, certain systems 
may send confirmation e-mails or alert notices to the user via e-mail. If the user 
submitted his or her e-mail address, the process continues to block 1340. 
Otherwise, the process continues directly to block 1350. 
15 At block 1340, the e-mail address submitted to the DS is altered. 

Specifically, the e-mail address is bifurcated, generated two e-mails. The first e- 
mail goes to the user's e-mail address, as entered. The second e-mail goes to the 
IIM. The second e-mail includes in its address the IIM and the transaction tag 
that identifies the transaction number to which the e-mail belongs. This allows 
20 the IIM to handle the e-mail. The process then returns to block 1350. 

At block 1350, the IIM records a transaction in the user's transaction 
database and associates the submitted information with the transaction. The 
transaction, for one embodiment, has a transaction number. 

At block 1360, the IIM determines whether there is a response from the 
25 DS. If there is a response, the process continues to block 1370. Otherwise, the 
process continues directly to block 1380. 

At block 1370, the IIM records the response from the DS in the user's 
transaction database. For one embodiment, the destination server may respond 
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to the user. This response is associated with the transaction record. In this way, 
the user may review the transaction record, including the response. 

At block 1380, further information is recorded about the transaction. For 
one embodiment, this information may include the date and time of the 

5 transaction, and other information. 

At block 1390, any notes, data, or e-mails received with the transaction tag 
are attached to the transaction. This may occur at any time, while the transaction 
is being recorded, or after that. The user may attach any data to the transaction, 
and the IIM may automatically attach any e-mails received with the transaction 

10 tag. 

At block 1395, the process ends. 

Figure 14 illustrates one embodiment of the listing of transactions. The 
transaction list 1410 may be sorted by date, using a menu 1425. The transactions 
may also be sorted by type 1435. For one embodiment, alternative methods of 

15 searching transactions may also be implemented. For example, a user may 
search the transaction records for purchases from a certain destination server. 

Each transaction record may include one or more of the following: date 
1420, transaction type 1430, and description 1440 of the transaction. The record 
may further include the place 1450, the location from where the transaction was 

20 recorded. The user may add and edit additional notes 1460. Furthermore, the 
user may also add attachments 1415 to the transaction record. For example, the 
user may attach e-mails, documents, video, or other types of data. For one 
embodiment, e-mails may be redirected through the IIM and automatically 
attached to the transaction. 

25 The vendor response 1470 is also recorded. The information the user 

provided 1480 during the transaction is also included in the transaction record. 
The transaction may further include the information whether the transaction 
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belongs to one of the accounts 1490 in the user's account database. The user is 

permitted to delete selected transaction records using a delete button 1465. 

Figure 15A is a flowchart of one embodiment of selection of a home page. 

The user connects to the IIM at block 1505. 
5 At block 1510, the user accesses a destination server page through the EM. 

At block 1515, the process determines which option the user is selecting. 

If the user is selecting the add bookmark option, the process continues to 

block 1525. At block 1525, the address of the page is added to the user's 

bookmark database. This database is accessible to the user, to permit the user to 
10 access various web sites without typing the address of the site. The process then 

continues to block 1530, and ends. 

If the user selected the set home page option at block 1515, the address of 

the page is set as the user's homepage. The user's homepage is called up when 

the user initially connects to the IIM. For one embodiment, the homepage is 
15 preset. For another embodiment, the user may not alter the homepage, and the 

homepage is customizable but includes advertising. The process then continues 

to block 1530, and ends. 

Figure 15B is a flowchart of one embodiment of using the bookmark 

functionality. At block 1535, the user connects to the IIM. At block 1540, the user 
20 requests access to the user's bookmarks through the IIM user interface. For one 

embodiment, the user requests the bookmarks by pressing the "Tags" button on 

the user interface. 

At block 1545, the IIM generates a bookmark list from the user's 

bookmark database, and sends the list to the client browser to display. For one 
25 embodiment, the bookmark list is displayed in the destination server display 

area. For another embodiment, the bookmark list is displayed in a separate 

window, or a separate frame. 
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At block 1550, the user selects a bookmark to access a destination server 

page. 

At block 1555, the IIM fetches the page address corresponding to the 
selected bookmark from the bookmark database. The bookmark database 
5 includes the actual address of the bookmark. 

At block 1560, the destination server page is fetched by the IIM. The data 
from the destination server is instrumented and is sent to the client browser for 
display. In this way, the user can access bookmarks stored in the IEVTs 
bookmark database. The process then continues to block 1565, and ends. 
10 Figure 15C is a flowchart of one embodiment of using the history 

functionality. At block 1570, the user connects to the EM. 

At block 1575, the user requests access to the history list through the IIM 
user interface. The history list includes the sites the user previously visited. For 
one embodiment, the history list is maintained for only a period of time, such as 
15 thirty days. For another embodiment, the history list is maintained indefinitely, 
and may be purged by the user. 

At block 1580, the IIM generates a history list from the user's history 
database, and sends the history list to the client browser for display. For one 
embodiment, the history list is displayed in the destination server display area. 
20 For another embodiment, the history list is displayed in a separate window, or a 
separate frame 

At block 1582, the user selects a list entry to access the destination server 
page. At block 1585, the IIM fetches the page address from the history database. 
The page address is referenced through the IIM. 
25 At block 1590, the IIM fetches the destination server page, instruments the 

communication, and sends the data to the client browser for display. At block 
1595, the process ends. In this way, the IIM permits a user to access a variety of 
services through the IIM. 
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Figures 16A-C show sample alterations of references from the destination 
server by the IIM. Figures 16A-C illustrate changes to HTML, HTTP protocol, 
JavaScript, and Java. For one embodiment, this technique may be expanded to 
new languages and other types of interfaces. The data that is normally 
5 communicated directly between a Destination Server (DS) and client browser is 
altered by the IIM, as shown by Figures 16A-C. For one embodiment, some data 
may be transmitted directly between the DS and the client browser, without 
passing through the IIM. 

For one embodiment, the IIM performs a subset of the message 
10 modifications required for redirection and downloads the client component to 
the client's browser, which performs the remaining subset of message 
^ modifications on the client machine. Together these two subsets of message 

modifications provide a complete solution for using an independent 
?!;! intermediary mechanism between a client and a server. 

r : i 15 The modification of HTTP communication messages for redirection occurs 

^' on both the IIM and the client browser using the client component. The points at 

Q which the message modifications occur are called "HTTP control points". 

Figures 16A-C illustrate examples of HTTP control points that occur on 

s !:!i ? 

the client browser and the IIM. For HTTP message documents, description of 
^ 20 modification code covers the three programming languages that are most widely 
used today for HTTP communication: HTML, JavaScript and Java. For another 
embodiment, the IIM utility may be broadened to include HTTP control points in 
other programming languages used for HTTP message documents. For one 
embodiment, the protocol modified in the messages is defined by the HTTP 
25 specification standard. One skilled in the art would understand how to expand 
the technique described to different programming languages or message 
protocols. 
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Figure 17 is a table illustrating examples of making the EM user interface 
frame persistent. The DM prevents DS's from overwriting the user interface of 
the IIM. This permits the user to access the IIM regardless of what DS he or she 
is accessing. 

5 Figure 18 is a table illustrating examples of accessing cookies from the 

IIM. Generally, the destination server and destination server data on the client 
system access the cookie cache on the client's computer system. The IIM 
modifies the access mechanisms to access cookies from the IIMs cookie database. 
Figure 19 is a table illustrating examples of preserving top frame or IIM 

10 frame integrity for DS. Objects are often hung from the top frame of the client 
browser. The IIM changes the references to the top frame to create or access 
these objects to references to the top frame of DSDA. In this way, the objects are 
appropriately handled . 

Figures 16-19 list some sample alterations resulting from the code 

15 instrumenting described above. Alternative methods of altering the code may be 
used. One skilled in the art knows how to implement different changes. 

In the foregoing specification, the invention has been described with 
reference to specific exemplary embodiments thereof. It will, however, be 
evident that various modifications and changes may be made thereto without 

20 departing from the broader spirit and scope of the invention as set forth in the 
appended claims. The specification and drawings are, accordingly, to be 
regarded in an illustrative rather than a restrictive sense. 
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CLAIMS 

What is claimed is: 

1 1. A method of accessing data through an independent intermediary 

2 mechanism (IIM), the method comprising: 

3 displaying a frame including a user interface of the IIM, the frame framing 

4 a destination server display area (DSDA); 

5 retrieving destination server data (DS data) for display from a destination 

6 server; 

7 maintaining a history list of past addresses of destination servers visited 

8 by the user. 

1 2. The method of claim 1, further comprising: 

2 permitting access to the history list through the user interface. 

1 3. A method of accessing data through an independent intermediary 

2 mechanism (IIM), the method comprising: 

3 displaying a frame including a user interface of the IIM, the frame framing 

4 a destination server display area (DSDA); 

5 displaying a homepage to the user, when the user initially connects to the 

6 IIM; 

7 permitting the user to access a destination server from the IIM; and 

8 retrieving destination server data (DS data) for display from a destination 

9 server. 

1 4. The method of claim 3, further comprising: 

2 the user selecting a page as the homepage. 
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1 5. A method of accessing data through an independent intermediary 

2 mechanism (IIM), the method comprising: 

3 displaying a frame including a user interface of the IIM, the frame framing 

4 a destination server display area (DSD A); 

5 retrieving destination server data (DS data) for display from a destination 

6 server; 

7 maintaining an account list for the user, the account list permitting one- 

8 key log-in into a plurality of accounts on the account list. 

1 6. The method of claim 5, further comprising: 

2 displaying the account list in response to a display request; and 

3 logging on to an account automatically when the account is selected. 

1 7. The method of claim 6, further comprising: 

2 displaying an account edit screen in response to an account edit request; 

3 and 

4 adding a new account, including an account location, an account log-in 

5 name, and an account password; and 

6 displaying the new account on the account list. 

1 8. A method comprising: 

2 accessing a destination server through an independent intermediary 

3 mechanism (IIM); and 

4 accessing a destination server site including a form; 

5 receiving a request to fill in the form; and 

6 filling in the form from a database in the IIM. 

1 9. The method of claim 8, wherein the step of filling in the form 

2 comprises: 
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3 determining if the user has a transaction record including the form; and 

4 if the user has a transaction record including the form, filling in the form 

5 from the transaction database. 

1 10. The method of claim 9, further comprising: 

2 determining if the user has changed an item in a user profile that is used 

3 in the form; and 

4 if the user has changed data, filling in the item from the user profile. 

1 11. The method of claim 10, wherein said step of determining 

2 comprises: 

3 comparing a date of the transaction record with a date of changes in the 
7; 4 user profile; and 

5 if the date of the transaction record is older, determining if the changes in 
m 6 the user profile are of a relevant record. 

" ■ 1 12. The method of claim 8, wherein said step of filling in the form 

Q 2 comprises: 

k* 3 determining if the form is in the form database; and 

% 4 if the form is in the form database, filling in the form based on information 

-£ e 5 in the user profile. 

1 13. The method of claim 12, wherein the forms database includes a 

2 plurality of forms, such that locations in the form mapped into elements in the 

3 user profile. 

1 14. The method of claim 12, wherein the forms database comprises 

2 multiple databases, at least one of the databases being centrally maintained. 
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1 15. The method of claim 12, further comprising the step of adding new 

2 forms to the form database, wherein the step of adding new form comprises: 

3 opening a new form at a new address; 

4 associating form control identifiers in the new form with labels from a 

5 user profile database; and 

6 storing the new form, the new address, and the associated form control 

7 identifiers in the forms database. 

1 16. The method of claim 12, wherein the form database is maintained 

2 in a central location, and administered by an authorized updater, such that an 

3 IIM updates an internal form database from the central location. 

1 17. The method of claim 8, wherein the step of filling in the form 

2 comprises: 

3 determining if the form is in a transaction database, 

4 if the form is in the transaction database, filling in the form based on 

5 information in the transaction database; 

6 if the form is not in the transaction database, determining if the form is in 

7 a form database, 

8 if the form is in the form database, filling in the form based on information 

9 in the form database and in a user profile; and 

10 if the form is not in the form database, matching entries in the user profile 

11 to form control identifiers in the form, and filling in the form based on the 

12 information from the user profile. 

1 18. A method comprising: 

2 accessing a destination server through an independent intermediary 

3 mechanism (IIM); and 
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4 receiving an indication to add a universal resource indicator (URI) of the 

5 destination server as a bookmark; 

6 adding the URI as a bookmark in the IIM. 

1 19. The method of claim 16, wherein the bookmark is located within a 

2 user database on the IIM. 

1 20. A method comprising: 

2 accessing a destination server through an independent intermediary 

3 mechanism (IIM); and 

4 when a user submits a form to the destination server through the EM, 

5 recording a transaction entry in a user's transaction database; and 

6 associating submitted information and form with the transaction; 

7 wherein the transaction is available for review to the user through the IIM. 

1 21 . The method of claim 20, further comprising updating a form entry 

2 in a form database in the IIM, based on the form submitted by the user. 

1 22. The method of claim 20, further comprising the step of updating a 

2 user profile based on the information submitted in the form. 

1 23. The method of claim 20, further comprising: 

2 determining if the destination server replied to the submission of the 

3 information; and 

4 if the destination server replied, 

5 recording the reply; and 

6 associating the reply with the transaction. 
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1 24. The method of claim 20, further comprising the steps of: 

2 adding one or more of the date, time, and other information to transaction 

3 record. 

1 25. The method of claim 20, wherein the user can selectively turn on 

2 and off the transaction recording facility. 

1 26. The method of claim 20, further comprising when a user accesses a 

2 destination server including a form, 

3 determining if the user has a transaction record including the form; 

4 and 

5 if the user has the transaction record, optionally filling in the data 

6 into the form based on the submitted information in the transaction record. 

1 27. The method of claim 26, wherein the user selects the option of 

2 filling in the data from a user interface of the IIM. 

1 28. The method of claim 20, further comprising when a user accesses a 

2 destination server including a form, 

3 determining if a form database includes the form; and 

4 if the form database includes the form, optionally filling in the data 

5 into the form based on a user profile. 

1 29. The method of claim 28, wherein the user selects the option of 

2 filling in the data from a user interface of the IIM. 

1 30. The method of claim 28, wherein the forms database includes a 

2 plurality of forms, such that locations in the form mapped into elements in the 

3 user profile. 
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1 31. The method of claim 21, further comprising: 

2 adding new forms to the forms database by an authorized updater. 

1 32. The method of claim 31, wherein the step of adding new form 

2 comprises: 

3 opening a new form at a new address; 

4 associating form control identifiers in the new form with labels from a 

5 user profile database; and 

6 storing the new form, the new address, and the associated form control 

7 identifiers in the forms database. 

1 33. The method of claim 31, wherein the form database is maintained 

2 in a central location, and administered by the authorized updater, such that an 

3 IIM updates an internal form database from the central location. 

1 34. The method of claim 7, further comprising: 

2 registering information when the user logs on to a new account; and 

3 adding the new account to the account list. 

1 35. The method of claim 34, wherein the user can optionally enable or 

2 disable the registering of information. 

1 36. The method of claim 34, further comprising: 

2 requesting a user response whether to add the new account to the account 

3 list, and only adding the new account to the account list if the user responds 

4 affirmatively. 
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ABSTRACT OF THE DISCLOSURE 

A method and apparatus of accessing data through an independent 
intermediary mechanism (IIM) is described. The method includes displaying a 
frame including a user interface of the IIM, the frame framing a destination 
5 server display area (DSDA). The method further includes having one or more of 
the following functions provided by the IIM: a home page, a history list, 
bookmarks, a one-click account log-in function, a transaction record accessible to 
the user, a forms database permitting new forms to be added to the forms 
database, a user profile, and automatic form-fill function based on the forms 
10 database and the user profile. 
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User requests access to 
history through Ul 
1575 



IIM generates a history 
list from user's history 
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CB to display 
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Original Code 


Altered Code 


Comments 


HTML 






<base href="anyURL"> 


<base 

nreT= nnpv/www. Ub.com/myDo 
cument.html"> 

<base href="anyURL"> 


www.DS.com is the hostname 
of the DS. The 1IM inserts the 
first <BASE> tag line after the 
<HTML> tag and before the 
<HEAD> tag, and before any 
existing <BASE> tags 


<form action=7actionURL"> 


SaveOrigAction( form, 
action URL) 

<form action=" 

http://www.IIM.com/redirect7act 
=http://www. DS.com 
/actionURL"> 


www.IIM.com is the hostname 
of the MM and www.DS.com is 
the hostname of the DS. 
SaveOrigAction() is a 
Javascript function that saves 
the form's original action. 


code="app!et.class"> 


<applet codebase=" 
http://www. 1 1 M .co m/red i rect?cb 

http://www.DS.com/codebase" 
wuc- appiei. ciass > 


www.IIM.com is the hostname 
of the IIM and www.DS.com is 
the hostname of the DS. 


<frame src="/mvFrarriA html'S» 

^• ||U| "^ oiv— /iiiyi i cii I icj til 1 II •» > 

other tags, e.g., <script>, 
<area>, <layer> , <img> 


<frame 

s rc="http://ww w. 1 1 M .com/red i re 

ct?src=http://www.DS.com/myF 

rame.htmlV 


www.IIM.com is the hostname 
of the IIM and www.DS.com is 
the hostname of the DS. 






link-href = "newLocation" 


setURLProperty ( link, "href", 
"newLocation" ) 


setURLProperty() sets the 
value of the property href to the 
value 

"http://w ww. 1 1 M .com/red irect?u r 
l=http://www. DS.com/newLocat 
ion", where www.IIM.com is the 
hostname of the IIM and 
www.DS.com is the hostname 
of the DS. 


link.onclick = originalOnClick 


function 

addNewLinkOnclick(link){ 
link.onclickOrig = 

link.onclick; 
link.onclick = 

newLinkOnclick; } 

function newLinkOnclick(link){ 
if ( link.originalHref == null ) 
Hnk.originalHref = linkhref; 
var newHref = 

getFullPathName( 
link.originalHref ); 
link.href = 

http://www. 1 1 M .co m/red i rect ? u rl 
=newHref; 

return link.onclickOrigO; } 


getFuilPathName() returns the 
full pathname URL of the 
HTML and www.IIM.com is the 
hostname of the IIM. The 
function addNewLinkOnclick() 
is called when the HTML 
document is first loaded 
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Original Code 


Altered Code 


Comments 


uucumeni.wriie^oiring i ovvni©; 


write Document ( document, 
StringToWrite ); 


writeDocument() recursively 
modifies all HTTP control 
points that occur in 
StringToWrite 


window.open( newLocation ); 


open Window ( window, 
newLocation ); 


openWindow calls 
window.open() with the 
argument 

"http://www.IS.com/redirect7url 
=http://www. DS.com/newLocati 
on" 


form.onsubmit = 
originalOnSubmit 


function 

addNewFormOnsubmit(form){ 
form.onsubmitOrig = 

form.onsubmit; 
form.onsubmit = 

newFormOnsubmit; } 

function 

newFormOnsubmit ( form ) { 
if (form.originalAction = null) 
{form.originalAction = 
form.action;} 

var newAction = 

getFullPathName(form.original 

Action); 

form.action = 

1-11 ■ //»-. nil / ■* _ f\, » 

http ://www. 1 1 M .com/red i rect? u rl 
=newAction; 

return form.onsubmitOriaO: 1 


getFullPathNameO returns the 
full pathname URL of the 
HTML document and 
www.IIM.com is the hostname 
of the IIM. The function 
addNewFormOnsubmitO is 
called when the HTML 
document is first loaded 








class java.net.Socket 


Extends java.netSocket and 
overrides various constructors. 


The extended method modifies 
the host and port arguments. 
The modified host argument is 
the hostname of the IIM. The 
modified port argument is the 
port of the IIM 


java.appletAppletContext 


Extends 

java.applet.AppletContext and 
overrides various constructors 


The extended method modifies 
the url argument. The modified 
url sends the HTTP request to 
the IIM with the full pathname 
of the original url as a query 
parameter 


class java.applet.Applet 


Extends java.applet.Applet and 
overrides various constructors 


The extended method modifies 
the url argument. The modified 
url sends the HTTP request to 
the IIM with the full pathname 
of the original url as a query 
parameter 
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Original Code 


Altered Code 


| Comments 


HTTP:Headers : -r--v- 






referer, 

e.g. value = origDoc.htm 


referer 

http://www.DS.com/origDoc.ht 
m 


reierer value is replaced with 
the full pathname of the 
document's original URL 


content-type, 
value = null 


content-type, 

e.g., value = image/gif 


If the value of content-type is 
nun, ine hm sets this header to 
a value that describes the type 
of content contained in the 
document. 


refresh, 
e.g. 

5000; origDoc.htm 


5000; 

http ://www. 1 S.com/red i rect? ref = 

http://www.DS.com/origDoc.ht 

m 


IIM replaces the URL portion of 
the value of the refresh header 
with the full pathname of the 
document's original URL 


301, 302 status codes, 

e.g., URI value = 

http://www.DS.com/origDoc.ht 
ml 


301, 302 status codes, 
URI value = 

httn"//www 1^ /^rtm/rcir(iror*fOi iri 

i nip.// www.io.wi 1 1/ Ftjuirsci : un = 

http://www.DS.com/origDoc.ht 
ml 


www.IIM.com is the hostname 
of the IIM 


201,303, 305, 307 status 
codes 

URI values 


201,303, 305, 307 status 
codes 

modified URI values 


See 301 , 302 status codes 
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Original Code Altered Code 


Comments 






target = "_top" 

for <a href>, <frame>, <form> 
and <base> tags 


target = "DSFrameName" 


where DSFrameName is the 
name of the DSDA top frame. 


target = "_parent" 

for <a href>, <frame>, <form> 
and <base> tags 


target = "DSFrameName" 


wiiere LJorramei\ame is ine 
name of the DSDA top frame, if 
the current window evaluates 
to the DSDA top frame. 






top.locationProperty = value 


setTopProperty ( 
currentWindow, 
IocationProperty, value ) 


sei i oprroperty sets a location 
property on the DSDA top 
frame with name 
IocationProperty to have value 
value 


window Darpnt 

II W iUUI CI III 

iocationProperty = value 


set i oprroperty ( 
window.parent, 
IocationProperty, value ) 


setTopProperty sets a location 

property on the DSDA top 

irame wiin name 

location r rope ny to nave value 

value if window.parent 

evaluates to the top or MM 

frame 


Java 


- - ' - - - 




java.applet.AppletContext.show 
Document( url, target ) 


newShowDocument ( window, 
url, target ) 

{ 

java.applet.AppletContext.show 
Document( url, newTarget ) 
} 


newShowDocument calls 
java.applet.AppletContext.show 
Document where newTarget is 
the name of the DSDA frame if 
target equals Mop" or if target 
equals "_parent" and window is 
the DSDA frame, "newTarget" 
is set to "target" otherwise. 
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Original Code 


| Altered Code 


1 Comments 




• : • , = : 




string = document.cookie 


string = getCookie( window, 
document ) 


getCookie() gets the cookie's 

VflllJP from thp IIM anrl occinnc 
v ciiuc iivjiii ii its ll Ivl ctMU doolUrio 

thp Vfllup tn Qtrinn 


document.cookie = 
cookieString 


setCookie{ window, document, 
cookieString) 


setCookie() sends the value of 

cookipStrinn tn thp IIM \r\ ha 

managed 


HTTP Headers 


=■■:.:': ^m^x/:^y-y- . >-^> 






cookie 


IIM sends this header to the DS 
on a need basis 


Java : 






javax.serviet.http.Cookie 


public class ISCookie 
implements Serializable { 

orivate Ion a creationTimp* 

public boolean hasExpired(){ 
// expiration function code } 
} 


maintains the cookie's creation 
time and contains convenience 
routines that determine if the 
ouuKie nas expirea 


Cookies 


public class Cookies extends 
PersistentObject implements 
Serializable { 

public String getCookie (URL 
url){} 

public static Cookie 
parseCookie(String str) { } 

public void 

addCookie(ISCookie coo, URL 
url){} 

private boolean 

validCookie(ISCookie coo, URL 
url) { } 

} 


extends the Java persistent 
object class, and saves in a 
user database the user-specific 
cookie information that the DS 
sent in the set-cookie header 
This class also finds the 
cookies in the cookie database 
that are valid for a certain URI 
based on well known Cookie 
rules and returns a Cookie 
string for a given URI. 
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Original Code 


Altered Code 


Comments 








window, location = newLocation 


setLocation(currentWindow, 
window, newLocation) 


setLocation() sets the 
window.location to the value 
"http ://www. 1 1 M .com/red i rect ? u r 
i— nup.//www. UvD.com/newLocai 
ion", where www.IIM.com is the 
hostname of the IIM and 
www.DS.com is the hostname 
of the DS. 


savpLoration — 
window.location 


oclVfcfLUUclUUM — 

getLocation(currentWindow, 
window) 


wnere geiLocation returns 
window.location except when 
window is equal to the top 
frame, then it returns the DSDA 


top.userProperty = value 


setTopProperty ( 
currentWindow, userProperty, 
value ) 


where setTopProperty sets a 
user property on the DSDA top 
frame with name userProperty 
to have value value 


window.parent.userProperty = 
value 


setTopProperty ( 
window.parent, userProperty, 
value ) 


where setTopProperty sets a 
user oroDertv on the DSDA too 
frame with name userProperty 
to have value value if 
window.parent evaluates to the 
top frame. 
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Duty to Disclose Information Material to Patentability 



(a) A patent by its very nature is affected with a public interest. The public interest is best served, 
and the most effective patent examination occurs when, at the time an application is being examined, the 
Office is aware of and evaluates the teachings of all information material to patentability. Each individual 
associated with the filing and prosecution of a patent application has a duty of candor and good faith in 
dealing with the Office, which includes a duty to disclose to the Office all information known to that individual 
to be material to patentability as defined in this section. The duty to disclosure information exists with respect 
to each pending claim until the claim is cancelled or withdrawn from consideration, or the application becomes 
abandoned. Information material to the patentability of a claim that is cancelled or withdrawn from 
consideration need not be submitted if the information is not material to the patentability of any claim 
remaining under consideration in the application. There is no duty to submit information which is not material 
to the patentability of any existing claim. The duty to disclosure all information known to be material to 
patentability is deemed to be satisfied if all information known to be material to patentability of any claim 
issued in a patent was cited by the Office or submitted to the Office in the manner prescribed by §§1 .97(b)-(d) 
and 1.98. However, no patent will be granted on an application in connection with which fraud on the Office 
was practiced or attempted or the duty of disclosure was violated through bad faith or intentional misconduct. 
The Office encourages applicants to carefully examine: 

(1) Prior art cited in search reports of a foreign patent office in a counterpart application, and 

(2) The closest information over which individuals associated with the filing or prosecution of a 
patent application believe any pending claim patentably defines, to make sure that any material information 
contained therein is disclosed to the Office. 

(b) Under this section, information is material to patentability when it is not cumulative to 
information already of record or being made or record in the application, and 

(1 ) It establishes, by itself or in combination with other information, a prima facie case of 
unpatentability of a claim; or 

(2) It refutes, or is inconsistent with, a position the applicant takes in: 

(i) Opposing an argument of unpatentability relied on by the Office, or 

(ii) Asserting an argument of patentability. 

A prima facie case of unpatentability is established when the information compels a conclusion that a claim is 
unpatentable under the preponderance of evidence, burden-of-proof standard, giving each term in the claim 
its broadest reasonable construction consistent with the specification, and before any consideration is given to 
evidence which may be submitted in an attempt to establish a contrary conclusion of patentability. 

(c) Individuals associated with the filing or prosecution of a patent application within the 
meaning of this section are: 

(1 ) Each inventor named in the application; 

(2) Each attorney or agent who prepares or prosecutes the application; and 

(3) Every other person who is substantively involved in the preparation or prosecution of the 
application and who is associated with the inventor, with the assignee or with anyone to whom there is an 
obligation to assign the application. 

(d) Individuals other than the attorney, agent or inventor may comply with this section by 
disclosing information to the attorney, agent, or inventor. 
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